Device profiling for isolation networks

ABSTRACT

In one embodiment, a server instructs one or more networking devices in a local area network (LAN) to form virtual network overlay in the LAN that redirects traffic associated with a particular node in the LAN to the server. The server receives the redirected traffic associated with the particular node. The server determines a node profile for the particular node based in part on an analysis of the redirected traffic. The server configures the particular node based on the determined node profile for the particular node.

RELATED APPLICATION

This application claims priority to U.S. Provisional Patent Appl. No.62/408,423, filed on Oct. 14, 2016, entitled DEVICE PROFILING FORISOLATION NETWORKS, by Wetterwald, et al., the contents of which areincorporated herein by reference.

TECHNICAL FIELD

The present disclosure relates generally to computer networks, and, moreparticularly, to device profiling for isolation networks.

BACKGROUND

A new form of network attack is now taking shape, whereby the Internetof Things (IoT) is used to attack the rest of the world, as opposed tothe other way around. For example, a recent distributed denial ofservice (DDoS) attack exceeded 620 Gbps of brute force login attacks,nearly doubling that of previous peak attacks. While this was one of thelargest attacks recorded to date, there are additional factors that setit apart from a “standard DDoS.” Most significantly, the attack wasgenerated by a BotNet that was comprised primarily of IoT devices. Themajority of these devices were identified as security cameras and DVRsthat were used in “Small Office/Home Office” (SoHo) setups. Ofparticular interest is that the attack included a substantial amount oftraffic connecting directly from the BotNet to the target, rather thanreflected and/or amplified traffic, as seen in recent large attacksusing NTP and DNS vulnerabilities.

BRIEF DESCRIPTION OF THE DRAWINGS

The embodiments herein may be better understood by referring to thefollowing description in conjunction with the accompanying drawings inwhich like reference numerals indicate identically or functionallysimilar elements, of which:

FIG. 1 illustrates an example communication network;

FIG. 2 illustrates an example network device/node;

FIGS. 3A-3C illustrate an example isolation network formation;

FIG. 4 illustrates an example profile determination of a node in anisolation network; and

FIG. 5 illustrates an example simplified procedure for determining aprofile of a node in an isolation network.

DESCRIPTION OF EXAMPLE EMBODIMENTS Overview

According to one or more embodiments of the disclosure, a serverinstructs one or more networking devices in a local area network (LAN)to form virtual network overlay in the LAN that redirects trafficassociated with a particular node in the LAN to the server. The serverreceives the redirected traffic associated with the particular node. Theserver determines a node profile for the particular node based in parton an analysis of the redirected traffic. The server configures theparticular node based on the determined node profile for the particularnode.

Description

A computer network is a geographically distributed collection of nodesinterconnected by communication links and segments for transporting databetween end nodes, such as personal computers and workstations, or otherdevices, such as sensors, etc. Many types of networks are available,ranging from local area networks (LANs) to wide area networks (WANs).LANs typically connect the nodes over dedicated private communicationslinks located in the same general physical location, such as a buildingor campus. WANs, on the other hand, typically connect geographicallydispersed nodes over long-distance communications links, such as commoncarrier telephone lines, optical lightpaths, synchronous opticalnetworks (SONET), synchronous digital hierarchy (SDH) links, orPowerline Communications (PLC) such as IEEE 61334, IEEE P1901.2, andothers. In addition, a Mobile Ad-Hoc Network (MANET) is a kind ofwireless ad-hoc network, which is generally considered aself-configuring network of mobile routers (and associated hosts)connected by wireless links, the union of which forms an arbitrarytopology.

Smart object networks, such as sensor networks, in particular, are aspecific type of network having spatially distributed autonomous devicessuch as sensors, actuators, etc., that cooperatively monitor physical orenvironmental conditions at different locations, such as, e.g.,energy/power consumption, resource consumption (e.g., water/gas/etc. foradvanced metering infrastructure or “AMI” applications) temperature,pressure, vibration, sound, radiation, motion, pollutants, etc. Othertypes of smart objects include actuators, e.g., responsible for turningon/off an engine or perform any other actions. Sensor networks, a typeof smart object network, are typically shared-media networks, such aswireless or PLC networks. That is, in addition to one or more sensors,each sensor device (node) in a sensor network may generally be equippedwith a radio transceiver or other communication port such as PLC, amicrocontroller, and an energy source, such as a battery. Often, smartobject networks are considered field area networks (FANs), neighborhoodarea networks (NANs), personal area networks (PANs), etc. Generally,size and cost constraints on smart object nodes (e.g., sensors) resultin corresponding constraints on resources such as energy, memory,computational speed and bandwidth.

FIG. 1 is a schematic block diagram of an example computer network 100illustratively comprising nodes/devices 200 (e.g., labeled as shown,“root,” “11,” “12,”. . . “45,” and described in FIG. 2 below)interconnected by various methods of communication. For instance, thelinks 105 may be wired links or shared media (e.g., wireless links, PLClinks, etc.) where certain nodes 200, such as, e.g., routers, sensors,computers, etc., may be in communication with other nodes 200, e.g.,based on distance, signal strength, current operational status,location, etc. The illustrative root node, such as a field area router(FAR), may interconnect the local networks with WAN 130, which may houseone or more other relevant devices such as management devices or servers150, e.g., a network management server (NMS), a dynamic hostconfiguration protocol (DHCP) server, a constrained application protocol(CoAP) server, an outage management system (OMS), etc. Those skilled inthe art will understand that any number of nodes, devices, links, etc.may be used in the computer network, and that the view shown herein isfor simplicity. Also, those skilled in the art will further understandthat while the network is shown in a certain orientation, particularlywith a “root” node, the network 100 is merely an example illustrationthat is not meant to limit the disclosure.

Data packets 140 (e.g., traffic and/or messages) may be exchanged amongthe nodes/devices of the computer network 100 using predefined networkcommunication protocols such as certain known wired protocols, wirelessprotocols (e.g., IEEE Std. 802.15.4, WiFi, Bluetooth®, etc.), PLCprotocols, or other shared-media protocols where appropriate. In thiscontext, a protocol consists of a set of rules defining how the nodesinteract with each other.

FIG. 2 is a schematic block diagram of an example node/device 200 thatmay be used with one or more embodiments described herein, e.g., as anyof the nodes or devices shown in FIG. 1 above. The device may compriseone or more network interfaces 210 (e.g., wired, wireless, PLC, etc.),at least one processor 220, and a memory 240 interconnected by a systembus 250, as well as a power supply 260 (e.g., battery, plug-in, etc.).

The network interface(s) 210 include the mechanical, electrical, andsignaling circuitry for communicating data over links 105 coupled to thenetwork 100. The network interfaces may be configured to transmit and/orreceive data using a variety of different communication protocols. Note,further, that the nodes may have two different types of networkconnections 210, e.g., wireless and wired/physical connections, and thatthe view herein is merely for illustration. Also, while the networkinterface 210 is shown separately from power supply 260, for PLC thenetwork interface 210 may communicate through the power supply 260, ormay be an integral component of the power supply. In some specificconfigurations the PLC signal may be coupled to the power line feedinginto the power supply.

The memory 240 comprises a plurality of storage locations that areaddressable by the processor 220 and the network interfaces 210 forstoring software programs and data structures associated with theembodiments described herein. Note that certain devices may have limitedmemory or no memory (e.g., no memory for storage other than forprograms/processes operating on the device and associated caches). Theprocessor 220 may comprise hardware elements or hardware logic adaptedto execute the software programs and manipulate the data structures 245.Operating system 242, portions of which is typically resident in memory240 and executed by the processor, functionally organizes the device by,inter alia, invoking operations in support of software processes and/orservices executing on the device. These software processes and/orservices may comprise routing process/services 244, an illustrativeisolation network process 248, and an illustrative device profilingprocess 249, as described herein. Note that while process 248 andprocess 249 are shown in centralized memory 240, alternative embodimentsprovide for the processes to be specifically operated within the networkinterfaces 210, such as a component of a MAC layer (e.g., process 248a).

It will be apparent to those skilled in the art that other processor andmemory types, including various computer-readable media, may be used tostore and execute program instructions pertaining to the techniquesdescribed herein. Also, while the description illustrates variousprocesses, it is expressly contemplated that various processes may beembodied as modules configured to operate in accordance with thetechniques herein (e.g., according to the functionality of a similarprocess). Further, while the processes have been shown separately, thoseskilled in the art will appreciate that processes may be routines ormodules within other processes.

Routing process (services) 244 includes computer executable instructionsexecuted by the processor 220 to perform functions provided by one ormore routing protocols, such as proactive or reactive routing protocolsas will be understood by those skilled in the art. These functions may,on capable devices, be configured to manage a routing/forwarding table(a data structure 245) including, e.g., data used to makerouting/forwarding decisions. In particular, in proactive routing,connectivity is discovered and known prior to computing routes to anydestination in the network, e.g., link state routing such as OpenShortest Path First (OSPF), orIntermediate-System-to-Intermediate-System (ISIS), or Optimized LinkState Routing (OLSR). Reactive routing, on the other hand, discoversneighbors (i.e., does not have an a priori knowledge of networktopology), and in response to a needed route to a destination, sends aroute request into the network to determine which neighboring node maybe used to reach the desired destination. Example reactive routingprotocols may comprise Ad-hoc On-demand Distance Vector (AODV), DynamicSource Routing (DSR), DYnamic MANET On-demand Routing (DYMO), etc.Notably, on devices not capable or configured to store routing entries,routing process 244 may consist solely of providing mechanisms necessaryfor source routing techniques. That is, for source routing, otherdevices in the network can tell the less capable devices exactly whereto send the packets, and the less capable devices simply forward thepackets as directed.

Low power and Lossy Networks (LLNs), e.g., certain sensor networks, maybe used in a myriad of applications such as for “Smart Grid” and “SmartCities.” A number of challenges in LLNs have been presented, such as:

1) Links are generally lossy, such that a Packet Delivery Rate/Ratio(PDR) can dramatically vary due to various sources of interferences,e.g., considerably affecting the bit error rate (BER);

2) Links are generally low bandwidth, such that control plane trafficmust generally be bounded and negligible compared to the low rate datatraffic;

3) There are a number of use cases that require specifying a set of linkand node metrics, some of them being dynamic, thus requiring specificsmoothing functions to avoid routing instability, considerably drainingbandwidth and energy;

4) Constraint-routing may be required by some applications, e.g., toestablish routing paths that will avoid non-encrypted links, nodesrunning low on energy, etc.;

5) Scale of the networks may become very large, e.g., on the order ofseveral thousands to millions of nodes; and

6) Nodes may be constrained with a low memory, a reduced processingcapability, a low power supply (e.g., battery).

In other words, LLNs are a class of network in which both the routersand their interconnect are constrained: LLN routers typically operatewith constraints, e.g., processing power, memory, and/or energy(battery), and their interconnects are characterized by, illustratively,high loss rates, low data rates, and/or instability. LLNs are comprisedof anything from a few dozen and up to thousands or even millions of LLNrouters, and support point-to-point traffic (between devices inside theLLN), point-to-multipoint traffic (from a central control point to asubset of devices inside the LLN) and multipoint-to-point traffic (fromdevices inside the LLN towards a central control point).

An example implementation of LLNs is an “Internet of Things” network.Loosely, the term “Internet of Things” or “IoT” may be used by those inthe art to refer to uniquely identifiable objects (things) and theirvirtual representations in a network-based architecture. In particular,the next frontier in the evolution of the Internet is the ability toconnect more than just computers and communications devices, but ratherthe ability to connect “objects” in general, such as lights, appliances,vehicles, HVAC (heating, ventilating, and air-conditioning), windows andwindow shades and blinds, doors, locks, etc. The “Internet of Things”thus generally refers to the interconnection of objects (e.g., smartobjects), such as sensors and actuators, over a computer network (e.g.,IP), which may be the Public Internet or a private network. Such deviceshave been used in the industry for decades, usually in the form ofnon-IP or proprietary protocols that are connected to IP networks by wayof protocol translation gateways. With the emergence of a myriad ofapplications, such as the smart grid advanced metering infrastructure(AMI), smart cities, and building and industrial automation, and cars(e.g., that can interconnect millions of objects for sensing things likepower quality, tire pressure, and temperature and that can actuateengines and lights), it has been of the utmost importance to extend theIP protocol suite for these networks.

An example protocol specified in an Internet Engineering Task Force(IETF) Proposed Standard, Request for Comment (RFC) 6550, entitled “RPL:IPv6 Routing Protocol for Low Power and Lossy Networks” by Winter, etal. (March 2012), provides a mechanism that supports multipoint-to-point(MP2P) traffic from devices inside the LLN towards a central controlpoint (e.g., LLN Border Routers (LBRs) or “root nodes/devices”generally), as well as point-to-multipoint (P2MP) traffic from thecentral control point to the devices inside the LLN (and alsopoint-to-point, or “P2P” traffic). RPL (pronounced “ripple”) maygenerally be described as a distance vector routing protocol that buildsa Directed Acyclic Graph (DAG) for use in routing traffic/packets 140,in addition to defining a set of features to bound the control traffic,support repair, etc. Notably, as may be appreciated by those skilled inthe art, RPL also supports the concept of Multi-Topology-Routing (MTR),whereby multiple DAGs can be built to carry traffic according toindividual requirements.

As described in greater detail below, isolation network process 248 maybe configured to form an “isolation network” that isolates a givennetwork node from a networking perspective and cause the traffic of thenode to be rerouted for analysis (e.g., by process 248). In some cases,isolation network process 248 may use the rerouted traffic to train amachine learning-based behavioral model of the node. In general, machinelearning is concerned with the design and the development of techniquesthat receive empirical data as input (e.g., data regarding theperformance/characteristics of the network) and recognize complexpatterns in the input data. For example, some machine learningtechniques use an underlying model M, whose parameters are optimized forminimizing the cost function associated to M, given the input data. Forinstance, in the context of classification, the model M may be astraight line that separates the data into two classes (e.g., labels)such that M=a*x+b*y+c and the cost function is a function of the numberof misclassified points. The learning process then operates by adjustingthe parameters a, b, and c such that the number of misclassified pointsis minimal. After this optimization/learning phase, experienceprediction process 248 can use the model M to classify new data points,such as a new traffic flow associated with the node. Often, M is astatistical model, and the cost function is inversely proportional tothe likelihood of M, given the input data.

In various embodiments, isolation network process 248 may employ one ormore supervised, unsupervised, or semi-supervised machine learningmodels to analyze traffic flow data. Generally, supervised learningentails the use of a training dataset, which is used to train the modelto apply labels to the input data. For example, the training data mayinclude sample traffic flows that are deemed “suspicious,” or “benign.”On the other end of the spectrum are unsupervised techniques that do notrequire a training set of labels. Notably, while a supervised learningmodel may look for previously seen network data that has been labeledaccordingly, an unsupervised model may instead look to whether there aresudden changes in the behavior of the node (e.g., the node suddenlystarts attempting a large number of connections to a previously unseendestination, etc.). Semi-supervised learning models take a middle groundapproach that uses a greatly reduced set of labeled training data.

Example machine learning techniques that isolation network process 248can employ may include, but are not limited to, nearest neighbor (NN)techniques (e.g., k-NN models, replicator NN models, etc.), statisticaltechniques (e.g., Bayesian networks, etc.), clustering techniques (e.g.,k-means, mean-shift, etc.), neural networks (e.g., reservoir networks,artificial neural networks, etc.), support vector machines (SVMs),logistic or other regression, Markov models or chains, principalcomponent analysis (PCA) (e.g., for linear models), multi-layerperceptron (MLP) ANNs (e.g., for non-linear models), replicatingreservoir networks (e.g., for non-linear models, typically for timeseries), random forest classification, or the like.

Security is one of the prime topics of concern for the IoT, and it couldbecome a roadblock for massive adoption if it is not properly addressed.Until now, there were very few attacks which targeted the IoT space, andIoT solutions for security are in fact very minimal (for the most partthey are extensions of firewalls with smart device signatures). Not onlycould the IoT attacks ramp up massively as IoT is being deployed, buttheir scale could be unprecedented due to the pervasive nature of thedeployment, and their complexity could become overwhelming consideringthe number of protocols involved.

As noted above, a new form of IoT attack is now taking shape, wherebythe IoT is used to attack the rest of the world, as opposed to the otherway around. For example, a recent distributed denial of service (DDoS)attack exceeded 620 Gbps of brute force login attacks, nearly doublingthat of previous peak attacks. While this was one of the largest attacksrecorded to date, there are additional factors that set it apart from a“standard DDoS.” Most significantly, the attack was generated by aBotNet that was comprised primarily of “Internet of Things” (IoT)devices. The majority of these devices were identified as securitycameras and DVRs that were used in “Small Office/Home Office” (SoHo)setups. Of particular interest is that the attack included a substantialamount of traffic connecting directly from the BotNet to the target,rather than reflected and/or amplified traffic, as seen in recent largeattacks using NTP and DNS vulnerabilities.

It is worth noting that this example attack was a DDoS attack, whereas awide range of highly concerning attacks target data leaking orextraction, exposing private data and confidential information withpossibly dramatic consequences.

The BotNet in the example above lived on the discrepancy betweenend-user expectations (e.g., a plug-and-play device) and the actualsystem they deploy (e.g., a UNIX computer connected to the Internet).

The Internet is facing a widespread issue that lowers user's confidencein IoT, such as where people suddenly discover that anyone can actuallysee into their home through that very camera they installed for their“protection”, without proper security measures and configuration takingplace. Effectively, the inside of thousands of homes may be exposed overthe Internet, and the next step for burglars could be to effectively usea recommendations engine to select the best house for tonight's robbery.

Notably, certain systems (e.g., a UNIX system as designed for a PC or aserver) comes with the capability to connect anywhere in the Internetover all sorts of protocols (SSH, HTTP, etc.) in a fashion that looksactually legit in the wire. These systems, in particular, often have thecapability to open ports in the firewall (STUN, TURN, ICE, etc.), andplace severe requirements on the end user, such as forcing frequentupdates to cope with newly found vulnerabilities, and requiring loginmanagement to prevent unwanted parties from accessing the system.

The user expectation is that it an IoT device is plug-and-play andlargely unmanaged. People do not know or care what a root user is andcannot imagine that their camera can dig gaping holes in their trustedfirewall. People also will not think of or know how to upgrade their IoTsystems. In fact, upgrades may not even be available from some vendors,which may either have disappeared from the market or may have rapidlylost interest in older systems in order to focus on producing new ones.Furthermore, the sheer volume of IoT devices implies a very quick andeasy installation process, commonly at the expense of weaker security(e.g., shared secret, PSK). A number of examples of such trade-offs isalready commercially distributed, and involves both consumer andprofessional grade equipment. The average IoT device often comesout-of-the-box with a well-known root password that will never bechanged (such as “admin/admin”), is reachable at an easily guessable IPaddress (e.g., in the 192.168.1.0/24 range) and is loaded withvulnerabilities that are fully documented in the dark web and will neverbe fixed. Basically, many IoT devices are open doors for hackers overthe Internet, and are much easier to compromise than a classical PC.

At this time, there are so many IoT devices that can be easilycompromised that the attacker does not care whether a particularcompromised device is detected. There needs to be no anonymity network(e.g., Tor Project), no redirection complexity, no weird packetconstruction that can be used to recognize a fraud. The attack comesstraight from apparently a plain user, using direct connectivity such asGRE tunnels, for which defenses are not really prepared, and which maybe a lot harder to sort out from real traffic.

Thus, an untrusted node may be applied in situations where a user has alimited a-priori understanding of the security posture of the device(e.g., vulnerabilities and credentials) and of its behavior, such as,e.g., opening ports for network address translation (NAT) usingUniversal Plug and Play (UPnP). Furthermore, a user may have no controlon the device software, as originally coming out of the box and thenalso through firmware updates.

An attack on an IoT device may leak private information to the internet,open the private network to attackers, as well as enable an incrediblypowerful BotNet. While BotNets may target the higher end of the IoT,such as TVs with hardware for video communication, video surveillance,and baby monitors, Trojan attacks may leverage any device, includingbathroom scales, medical care objects, remote controls, etc. to turn thefirewall and open NAT ports. Anything connected can become a backdoor tothe whole private network.

Operationally, FIGS. 3A-3C illustrate an example formation of theoverall architecture discussed herein. As shown in FIG. 3A, network 300comprises an IoT device in a network connecting to various sites,services, and/or applications. In particular, node 310 (e.g., a home orbuilding device including a security camera, a video/audio recordingdevice, a thermostat, a kitchen appliance, a bathroom scale, etc.) inlocal area network (LAN) 320 (e.g., a home or SoHo LAN or WLAN) mayconnect to one or more remote destinations outside of LAN 320 (e.g.,site/service 1-site/service 6, 361-366, and application/display 367),such as through external network 330 (e.g. a WAN). As shown, node 310may communicate via one or more networking devices 340 of LAN 320 (e.g.,wired or wirelessly) to access the various destination 361-367 and/orother destination nodes within LAN 320. As would be appreciated,networking device(s) 340 may include, but are not limited to, (wireless)access points (APs), switches, routers, a gateway that connects LAN 320to external network 330, combinations thereof, and the like. In general,node 310 may be able to access a wide variety of different sites andservices, some of which may be either unneeded or potentially harmful ordangerous to the device as well as to other devices within its localnetwork. As discussed above, securing the devices within LAN 320,particularly node 310, from attack may become increasingly challengingwith such unchecked accesses.

FIG. 3B illustrates a specific embodiment of the present disclosure inwhich an isolation network is formed in order to provide improvedsecurity for node 310. As shown, a server/service 380 in externalnetwork 330 may cause the formation of a virtual network overlay thatacts as an isolation network 370 for node 310. In the case ofcloud-computing environments, multiple devices may be used to provideservice 380. In such cases, the term “server” refers to the collectivedevices operating in conjunction with one another. Isolation network 370may, in some embodiments, include node 310, the one or more networkingdevices 340 of LAN 320, as well as one or more destinations with whichnode 310 is authorized to communicate. For example, sites/services365-366 are outside of isolation network 370 and, thus, traffic fromnode 310 to these sites/services would be blocked.

In more detail, in some embodiments, server/service 380 may instructnetworking device(s) 340 to bridge/tunnel traffic associated with node310 to server/service 380 for further analysis. For example, rather thansending a request from node 310 to site/service 361, the gateway of LAN320 may redirect the traffic via a tunnel to server/service 380 forfurther analysis. Server 380 could also re-inject the traffic receivedfrom node 310 via the networking device(s) 340 back towards thenetworking device(s), to let it be bridged or routed as initiallyintended. When doing so, it could provide detailed instructions,embedded into the tunnel header, to instruct the networking device(s)340 (e.g., a bridge or router), to restrict the way traffic should bebridged or routed.

As an example, assuming the networking device 340 is a switch, it mayreceive a multicast packet such as a Router Solicit (RS). Normally, theswitch would simply broadcast to all nodes. Instead, the RS may be sentto the server 380, server 380 may decide that it should only go to therouters, re-inject the received packet to the switch, but instruct itabout the 2 nodes. In turn, when the switch receives the packet, insteadof broadcasting, it may only replicate the packet to the two routers.

As part of the formation of isolation network 370, server/service 380may also generate a unique identifier for the virtual overlay ofisolation network 370. For example, server/service 380 may generate andsend a unique service set identifier (SSID) to networking device(s) 340,which node 310 can then use to access LAN 320 wirelessly (e.g., via awireless AP). Similarly, for wired communication (e.g., IEEE Std.802.15.4), the identifier may be a PAN-ID. When node 310 attempts tocommunicate outside of LAN 320, a communication may be received atserver/service 380 via the virtual overlay of isolation network 370, anda determination may be made by the device whether the destination of thecommunication is one of the authorized destinations that are within thevirtual overlay. The communication may then be sent to the destinationif it is determined that it is, in fact, an authorized destination.

As a specific embodiment of the present disclosure, a user may wish toconnect a new IoT device (e.g., node 310) to a home/SoHo network (e.g.,LAN 320), in order to access various applications, sites, and/orservices. Using these applications, sites, and/or services, the user maybe able to, for example, visualize his/her weight loss or share videosvia a smartphone where visualization of the video is possible, thesmartphone being potentially on the home network (e.g., within LAN 320)or roaming on the Internet. Using the techniques herein, the user maybrowse a page in a bubble care management system (e.g., server/service380) and may indicate that the IoT device is a new device. Notably, onlyminimal information about the device may need to be entered, such asdevice type, an image/picture of the device, or the manufacture's website, to be recognized by the bubble care management system.

In response to the registration request regarding node 310,server/service 380 may instruct networking device(s) 340 to form a newvirtual overlay/“bubble” that may redirect some or all of the trafficassociated with node 310 to server/service 380 for further processing.In some embodiments, server/service 380 may spawn a new virtual machine(VM) or container-based application associated with node 310 tospecifically handle the traffic associated with node 310. In the case ofVM-based implementations, each such application may be executed withinits own separately run operating system with its own set of binaries andlibraries, with a hypervisor overseeing the execution of each VM. Incontainerized implementations, however, the operating system itself, thebinaries, and/or libraries may be shared across applications asnecessary, on server/service 380. According to the techniques describedherein, the VM or containerized application of server/service 380 fornode 310 may auto-configure an IP prefix, such as an IPv6 unique localaddress (ULA) or an IPv4 private address, that is forged on the fly forthe virtual overlay of isolation network 370.

In some embodiments, such as for a wireless IoT node, server/service 380may send the unique SSID (e.g., a virtual-SSID) for isolation network370 to a user, as well as a password, if needed. Server/service 380 mayalso send this identifier to networking device(s) 340 of LAN 320,instructing these devices to accept a new Wi-Fi device having theestablished SSID/password. Note that the password may be optional sincethe SSID may not be exposed by the AP in its beacon, since it is not areal SSID. A similar approach may be taken in the wired case, such as bygenerating and sending a PAN-ID.

Thus, according to the techniques described herein, the user may enterthe virtual SSID and password (if needed) into node 310 as if they werenormal Wi-Fi credentials. The networking device(s) 340 (e.g., a wirelessAP) may then send a beacon looking for the SSID that was programmed, pernormal Wi-Fi behavior. Since this SSID has been communicated to thedevice AP and/or network gateway, node 310 would therefore be allowed inand associated. The authentication phase based on the SSID/password canbe handled either at the device AP or the bubble care VM. For example,in a controller model, the controller may perform the L2TP to the bubblecare VM. Traffic from node 310 may, in some embodiments, be encryptedwith a particular session key and would not be visible from otherdevices/nodes which use different keys and network settings.

According to further aspects of the techniques herein, the device (e.g.,the bubble care management service) may also instruct networkingdevice(s) 340 to bridge/tunnel (e.g., using L2TP) all the datagramsassociated with the SSID to the particular new bubble care VM orcontainer running on server/service 380. In this way, communicationsbetween node 310 and server/service 380 may only occur using tunnel 390within isolation network 370.

Networking devices 340 may bridge some or all of the traffic associatedwith node 310 to server/service 380, based on an established policy. Insome embodiments, server/service 380 may also train a learningmachine-based behavioral model for node 310 based on the receivedtraffic associated with node 310. For example, the VM or containerizedapplication that assesses the traffic associated with node 310 mayemulate the expected networking device(s) 340 and any other servers ordevices (e.g., a DNS server, etc.), from the perspective of node 310. Todo so, fields, such as the prefix in a router advertisement, may befilled with the forged ULA/private addresses generated for this virtualoverlay. In doing so, the machine learning-based model can “learn” thetraffic behaviors associated with node 310.

Since the interaction with the network appears “normal” from theperspective of node 310, node 310 forms or obtains IP addresses and isable to communicate with the Internet via the virtual overlay ofisolation network 370, but only if the destination is authorized byserver/service 380. For example, note, as shown in FIG. 3B, site/service5 (365) and site/service 6 (366) are not part of the virtual overlay ofisolation network 370 and, as such, would not be accessible to node 310(e.g., server/service 380 may drop traffic from node 310 to thesedestinations).

Authorized sites/services may be those that have been determined, based,for example, on the type of node 310, to be necessary (e.g., based onthe information regarding node 310 in the registration request),preferable, and/or safe for the device to access. For example, remotesites/services that provide configuration management, softwaremanagement (such as a vendor support site), security posture management,and/or various data publishers and subscriptions (e.g., YouTube, Google,etc.) may be authorized for inclusion in isolation network 370.Authorization may be based on either a pre-established knowledge base,which may be related to the particular brand/model/type of IoT device,or may be determined from information available related to the device.For example, a particular IoT device model may be permitted to connectto the manufacturer's site for downloading system software or to anapplication store for resident applications for that particular device.Authorized sites may also be determined based on target site reputationand/or heuristically.

The accessible destinations for node 310 may also be based in part onthe behavioral model for node 310. For example, in cases in which theexact type of node 310 is unknown, the behavioral model ofserver/service 380 may be used to determine the type of node 310 and itsauthorized destinations. In another embodiment, the model may be used todetect and block anomalous traffic associated with node 310 (e.g.,sudden and unexpected increases in traffic, etc.).

As shown in FIG. 3B, communications from node 310 are received atserver/service 380 through bridge/tunnel 390 from networking device(s)340, which helps to implement the virtual overlay of isolation network370. In this way, node 310 and its communications are protected withinisolation network 370 and are only permitted to specified authorizeddestinations, thereby preventing access to node 310 and protecting LAN320 from external potential threats. Server/service 380 may either proxythe request or may extend the ULA overlay to include a particularapplication. As a specific example, if a smartphone is used as adisplay, an application available on the smartphone may terminate a L3overlay (e.g., MIPv6 homed at the bubble care VM) that enables mobility.The VM of server/service 380 may monitor the traffic and may bridge whatis deemed to be legitimate to the smartphone over the MIPv6 tunnel.

Implementation of such overlay/isolation networks (e.g., a “bubble”) asdescribed herein may be dynamic and may bootstrap, isolate, monitor, andmanage computer devices, particularly IoT devices, through theirlifecycles, thereby addressing one of the key inhibitors of massive IoTdeployment. Additionally, isolation networks as described herein may becombined with behavioral analysis, applying the latest approaches tonetwork isolation and mobility under the control of learning machines(e.g., code implementing machine learning algorithms such as behavioralanalytics) that may be located in the cloud to benefit from crosslearning (e.g., learning from datasets belonging to different networks),though some actions can be delegated locally (e.g., Home Fog).

As described herein in some embodiments, a virtual overlay network(e.g., an isolation network/bubble) may be formed that includes the fewlogical network devices with which an IoT device primarily needs tocommunicate and, further, excludes unwanted or unneeded sites/services,such as a BotNet controller (e.g., Command & Control (C2) server) thatcould either trigger the device if already compromised or could become apotential target that the device would attack if already programmed forattack (e.g., if the device is in the bubble). The virtual overlaydescribed herein may protect the IoT device from remote attackers thatwould attempt to login to the device and compromise it, whether theattacker is far on the Internet (such as external network 330) or on thesame home network (such as LAN 320). The virtual overlay network mayalso enable transparent connectivity to mobile personal devices such asan application/display in a smartphone.

As an intelligent protection, the isolation network (e.g., the virtualoverlay network) may leverage rule-based and machine learning (ML)approaches. These techniques may be used to profile the device todetermine its type, so as to derive appropriate management techniques(e.g., http html page on poor 80 in the device) and the needs forconnectivity. Furthermore, the flows from/to the devices may thereby bevalidated and misbehaviors detected. In addition, appropriateconnections to Internet services may be allowed (e.g., software upgrade,publish/subscribe servers, management, etc.) inside the virtual overlayand, in some embodiments, multiple local devices may be allowed insidethe same “bubble” with the capability to either monitor or intercept thetraffic at some intelligence point in the cloud or to let the trafficflow locally with no data flowing outside of the device network (e.g., aLAN or WLAN). Rule-based and ML approaches may also be used to generateand push a configuration for the device that is adapted to the devicetype, including dedicated home SSIDs and passwords, root passwords,management servers and passwords, URL of support servers such assoftware update, etc., all based on simple user input, device profiling,and potential policy rules learned for the device profile. Furthermore,a set of rules may be generated and pushed to the first hop the deviceconnects to (e.g., a device AP, a gateway, etc.) to allow and controlshortcutting of specific flows between specific devices. Web pages thathave never been seen can be understood, recognizing fields andgenerating filled forms automatically.

In some embodiments, the techniques described herein are based on theparticular mechanisms that may allow formation of a virtual overlay toisolate a device in a local network (e.g., an IoT device), to extend thevirtual overlay to the cloud by creating a bubble care instance in thecloud, and to bridge the device traffic to the bubble care instance. Thetechniques may leverage learning machines (e.g., combination of rulesand machine learning algorithms) to emulate the interactions withrouters from the bubble care instance so the device starts normal L2/L3activity. Said differently, the techniques described herein may usenewly defined learning machine based mechanisms to isolate devices fromthe surrounding networks (e.g., LAN and the Internet), install thedevice in a virtual network (e.g., an isolation network) that isoverlaid over the Internet, where the virtual network incorporates a“bubble care cloud” application that controls the connectivity of thedevice. Thus, in some embodiments, the techniques herein may providefull isolation of each device and the bridging to a virtual machine inthe cloud on the fly, wherein the virtual machine may use artificialintelligence technology to respond to the device faking the required setof network devices.

FIG. 3C illustrates an example embodiment showing one potentialimplementation of server/service 380 in greater detail, according tovarious embodiments. As noted above, server/service 380 may comprise asingle server or, alternatively as shown, several servers that operatein conjunction with one another to implement the techniques herein aspart of a single remote service for the nodes in LAN 320.

In some embodiments, server/service 380 may comprise a provisioningserver 391 and a traffic analyzer server 392. During operation,provisioning server 391 may instruct networking device(s) 340 to form aspecific bubble/virtual overlay for one or more nodes in LAN 340 (e.g.,isolation network 370). For example, provisioning server 391 may be anIdentity Services Engine (ISE) from Cisco Systems, Inc., or similarserver that performs the provisioning (e.g., based on the profile ofnode 310). In doing so, provisioning server 391 may instruct networkingdevice(s) 340 to form a Layer 3 Virtual Extensible LAN (VXLAN) thatdirects traffic associated with node 310 to a traffic analysis server392 for analysis.

During establishment of isolation network 370, provisioning server 391may also instruct traffic analyzer server 392 to perform any number offunctions on the traffic associated with node 310. For example,depending on the profile of node 310, provisioning server 391 mayinstruct traffic analyzer server 392 to perform firewall functions onthe traffic, perform machine learning-based modeling of the traffic, orthe like. In some embodiments, provisioning server 391 may instructtraffic analyzer server 392 to execute these functions within a VM orcontainer associated with the specific isolation network 370.

In some cases, Application Policy Infrastructure Controller (APIC) 393in server/service 390 may also provide application user groupinformation to provisioning server 391 and/or to traffic analyzer server392. Such information may be used by server 391-392 to help control theprovisioning of isolation network 370 and/or the specific functionsperformed on the traffic by traffic analyzer server 392.

Device Profiling for Isolation Networks

A key aspect of the techniques herein is the ability for the isolationnetwork to profile a given node. For example, when an IoT device/node isconnected to the network for the first time (e.g., at home, in anenterprise, or on a public network), this device must be recognized todetermine the connectivity that is required and how the device may beconfigured. The techniques described herein leverage rule-based andmachine learning (ML) based profiling, traffic analysis, imagerecognition (e.g., if the user can send out a picture of the device),etc. in order to determine what the device is and to assess whether thedevice is behaving properly (e.g., respecting privacy) or whether it wasalready compromised.

Said differently, according to some embodiments of the techniquesdescribed herein, for an IoT device to be connected to a local networkfor the first time, the device may be automatically isolated from thelocal network and, through a specific validation process, may beprofiled before allowing it to connect to networks, applications orother devices. In some embodiments of the techniques described herein,profile information may be determined based on communication trafficbridged through the isolation network and received in the cloud from thedevice in order to identify the IoT type by using rules, heuristics, ormachine-learning classifiers, which, in some embodiments, may bedownloaded from an authorized destination in the isolation network, suchas the manufacturer site, or dynamically learned from existing IoTdevices successfully deployed.

Operationally, FIG. 4 illustrates an example profiling technique for IoTdevices connected to a local network. As shown, these techniques assumethat an isolation network is used to protect the IoT device, which, insome embodiments, may be formed using the various techniques describedabove. In particular, as shown in FIG. 4, a server/service 380 may causethe formation of a virtual network overlay that acts as an isolationnetwork 370 for node 310 in LAN 320 and one or more networking devices340. Isolation network 370 may further include one or more destinationswith which node 310 is authorized to communicate (e.g., site/service1-site/service 4, 361-364, and application/display 367).

As a result, the immune deficient node may be protected within anisolation network that appears as the Internet from the deviceperspective but is in fact highly restricted in connectivity. Protectedin this way, the techniques described herein may be used to discover thenode profile and validate that the particular node is not compromised.In some embodiments, the server/service may utilize specific profilingapplications in order to identify/categorize setup conditions forconfiguring the particular node (e.g., node 310) before allowing anyconnections that may be later be found to be harmful.

As shown in FIG. 4, since communication from node 310 may be received atserver/service 380 through bridge/tunnel 390 from networking device(s)340, the server/service can dialog with the particular node and emulateany conversation it may have with other parties across the Internet. Inthis way, a profile can be determined for the node based in part on ananalysis of the redirected communication traffic received byserver/service 380.

Typically, recognizing an IoT device has involved manually configuringrules for device profiling using, for example, on premise identityservices. IoT devices are then discovered using probes of variousprotocols (e.g., NMAP, DHCP, DHCP SPAN, HTT, HTTP SPAN, DNS, SNMP, AD,etc.) and making use of static rules to profile the device. However, thetechniques described herein may utilize, in some embodiments, a“cloud-based, extended identity service architecture” in whichcomponents are part of an isolation network. Thus, the identity servermay be “in-the-cloud” and no longer on premise, enabling managementoutside the local network (e.g., LAN 320) managed by a third party.

In some embodiments, profile information for the particular node (e.g.,node 310) may be received at server/service 380, and a node profile maybe determined from the received profile information. For example,dynamic inputs may be gathered from IoT device manufacturers, such asdevice identity management 495, which, in some embodiments, may be oneof the authorized destinations within the isolation network, and thereceived profile information may be used to identify the particularnode. Alternatively, such as in the case of the architecture shown inFIG. 3C, provisioning server 391 may perform the profiling functionsdescribed herein.

Profile information may be static (such as the device MAC address,serial number, hostname, operating system, operating system version,etc.). Alternatively, profile information may be determined fromrule-based behaviors. Thus, in some embodiments, a server (e.g.,server/service 380) may receive a set of node behavioral rules and mayapply these rules to the redirected traffic from the particular node todetermine the node profile. For example, complex rules may be downloaded(e.g., from device identity management 495) that allow for adeterministic identification of the node type according to its behavior(e.g., traffic type including destination/source address, user datagramprotocol/transmission control protocol (UDP/TCP) ports, etc., finitestate machines, etc.).

In some specific embodiments, a machine learning-based node behavioralmodel may be trained and used by the server to determine profileinformation for the particular node in the LAN. The model/algorithm maybe accessed within the network (e.g., downloaded from the manufacturer).As an example, a classifier such as an artificial neural network (ANN)or an ensemble learning method, such as a random forest, may be used. Insome embodiments, a set of features may be computed by the server (e.g.,server/service 380) from traffic received from one or more other nodesin the network, such as via the isolation network, in order to train amachine learning-based node behavioral model (e.g., feed a classifier).The output may allow for the determination of the node type by analyzingtraffic from the particular node using the trained model. Thus, in someembodiments, the techniques described herein may include profiling aparticular node in a LAN by a server within the isolation network usingtraffic dynamically bridged from the particular node using techniquessuch as rule-based and machine learning-based, either locally availableor dynamically retrieved, such as from the manufacturer of the node.

In other embodiments, server/service 380 may build its own model fordevice profiling once a particular node has successfully been added tothe LAN. A variety of inputs may be used, including, for example,message types, finite state machine, user's inputs (such as device brand(e.g., brand-x), type (e.g., webcam), device picture that learningmachines may recognize, etc.), MAC address, serial number, or otherprofile information used in initial networking exchanges or in initialrequests by the particular node after boot (such as Bonjour, universalplug and play (UPNP), contact by a known server, etc.).

Furthermore, it may also be possible for the network device to uploadand utilize rules or ML algorithms on premise (e.g., by using networkingdevice(s) 340 of LAN 320). In some embodiments, the redirected trafficfrom the particular node (e.g., node 310) may be analyzed using atrained node behavioral model deployed to one or more networking devicesin the LAN. Furthermore, traffic associated with the particular nodethat is not redirected to the server may also be analyzed. However, suchan approach may be handled with care since it requires enabling an agentto have access to the home gateway in order to identify the nodeprofile. Resources required to identify the particular node may requirelocal computation of the relevant features. This may be particularlyuseful when bridging all traffic to the server/service is costly, andlocal resources are available in the LAN, such as the home gateway, toperform the node profile identification.

FIG. 5 illustrates an example simplified procedure for determining aprofile for a device in an isolation network, in accordance with one ormore embodiments of the techniques described herein. For example, anon-generic, specifically configured device in a network (e.g., device200) may preform procedure 500 by executing stored instructions.Procedure 500 may start at step 505 and continue to step 510 where, asdescribed in more detail above, the server may instruct one or morenetworking devices in a local area network (LAN) to form a virtualnetwork overlay in the LAN that redirects traffic associated with aparticular node in the LAN to the server. The virtual network overlaymay act as an isolation network and may, in some embodiments, includethe particular node in the LAN, the one or more networking devices ofthe LAN, and one or more destinations with which the particular node isauthorized to communicate.

At step 515, as described in more detail above, the server may receivethe redirected traffic associated with the particular node. The trafficmay be wired or wireless communication. In some embodiments, the nodemay be an IoT device communicating via one or more networking devices ofthe LAN, such as a wireless access point, switch, router, gateway, orcombinations thereof.

At step 520, as described in more detail above, the server may determinea node profile for the particular node based in part on an analysis ofthe redirected traffic. In some embodiments, profile information may bestatic information, comprising a device identifier from a particulardestination in the network, such as a MAC address, a serial number, ahostname, an operating system type, or an operating system version. Inother embodiments, the profile information may be dynamic. For example,the server may determine the profile of a particular node in a LANwithin an isolation network using traffic dynamically bridged from theparticular node by applying a set of node behavioral rules or machinelearning-based node behavioral models to traffic from the node to the.These may be either locally available or dynamically retrieved, such asfrom the manufacturer of the node.

At step 525, as described in more detail above, the server may configurethe particular node based on the determined node profile for theparticular node. Since the node is protected within a virtual networkoverlay of an isolation network, the server may identify and/orcategorize setup conditions for configuring the particular node withoutconcern that connections could be made that would later be foundharmful. Procedure 500 may then end at step 530.

In various embodiments, any or all of steps 515-525 of procedure 500 maybe repeated as desired. For example, once the initial node profile hasbeen identified, and the node configured accordingly, the server maycontinuously or periodically monitor the traffic associated with thenode (e.g., all of the traffic or by sampling some of the traffic). Indoing so, the server may detect any behavioral deviations of the node bycomparing the traffic behavior of the node to that of its expectedbehavior (e.g., the behavior of a node having the determined nodeprofile). This monitoring can then lead to changes in profile of thenode itself and/or to initiate anomaly mitigation actions, such asblocking some or all of the traffic associated with the node.

It should be noted that while certain steps within procedure 500 may beoptional as described above, the steps shown in FIG. 5 are merelyexamples for illustration, and certain other steps may be included orexcluded as desired. Further, while a particular order of the steps isshown, this ordering is merely illustrative, and any suitablearrangement of the steps may be utilized without departing from thescope of the embodiments herein.

The techniques described herein, therefore, provide device profiling forisolation networks. In particular, in some embodiments, the techniquesherein may offer a secure way to deploy IoT solutions and prevent IoTdevices from polluting other devices or being the target of viruses andmalware. In some embodiments, the techniques herein may extendconventional identity services through the use of cloud-based devicetype recognition with learning machines, thus enabling the reuse oflearned parameters from one device to be used for all devices of itstype.

While there have been shown and described illustrative embodiments thatprovide for isolation networks, node profile determination, and relatedtechniques, it is to be understood that various other adaptations andmodifications may be made within the spirit and scope of the embodimentsherein. For example, while certain embodiments are described herein withrespect to using certain environments, such as the IoT, otherembodiments need not be limited to IoT devices. In addition, whilecertain protocols are shown, other suitable protocols may be used,accordingly.

The foregoing description has been directed to specific embodiments. Itwill be apparent, however, that other variations and modifications maybe made to the described embodiments, with the attainment of some or allof their advantages. For instance, it is expressly contemplated that thecomponents and/or elements described herein can be implemented assoftware being stored on a tangible (non-transitory) computer-readablemedium (e.g., disks/CDs/RAM/EEPROM/etc.) having program instructionsexecuting on a computer, hardware, firmware, or a combination thereof.Accordingly this description is to be taken only by way of example andnot to otherwise limit the scope of the embodiments herein. Therefore,it is the object of the appended claims to cover all such variations andmodifications as come within the true spirit and scope of theembodiments herein.

What is claimed is:
 1. A method comprising: instructing, by a server,one or more networking devices in a local area network (LAN) to form avirtual network overlay in the LAN that redirects traffic associatedwith a particular node in the LAN to the server; receiving, at theserver, the redirected traffic associated with the particular node;determining, by the server, a node profile for the particular node basedin part on an analysis of the redirected traffic; and configuring, bythe server, the particular node based on the determined node profile forthe particular node.
 2. The method of claim 1, further comprising:receiving, at the server, a set of node behavioral rules; and applying,by the server, the set of node behavioral rules to the redirectedtraffic from the particular node, to determine the node profile for theparticular node.
 3. The method of claim 1 further comprising: receiving,at the server, a machine learning-based node behavioral model; andapplying, by the server, behavioral model to the redirected traffic fromthe particular node, to determine the node profile for the particularnode.
 4. The method of claim 3, wherein the machine learning-based nodebehavioral model comprises a traffic classifier.
 5. The method of claim1, wherein determining the node profile for the particular node based inpart on the analysis of the redirected traffic comprises: training, bythe server, a machine learning-based node behavioral model using trafficfrom one or more other nodes; and analyzing, by the server, theredirected traffic from the particular node using the trained nodebehavioral model.
 6. The method of claim 5, wherein the node behavioralmodel is trained using the traffic from the one or more other nodesafter boot of the one or more other nodes.
 7. The method of claim 1,wherein analyzing the redirected traffic from the particular node usingthe trained node behavioral model comprises: deploying, by the server, anode behavioral model to a networking device in the LAN, wherein thenetworking device uses the node behavioral model to analyze trafficassociated with the particular node that is not redirected to theserver.
 8. An apparatus comprising: one or more network interfaces tocommunicate with a network; a processor coupled to the networkinterfaces and configured to execute one or more processes; and a memoryconfigured to store a process executable by the processor, the processwhen executed configured to: instruct one or more networking devices ina local area network (LAN) to form a virtual network overlay in the LANthat redirects traffic associated with a particular node in the LAN tothe apparatus; receive the redirected traffic associated with theparticular node; determine a node profile for the particular node basedin part on an analysis of the redirected traffic; and configure theparticular node based on the determined node profile for the particularnode.
 9. The apparatus as in claim 8, wherein the process when executedis further configured to: receive a set of node behavioral rules; andapply the set of node behavioral rules to the redirected traffic fromthe particular node, to determine the node profile for the particularnode.
 10. The apparatus as in claim 8, wherein the process when executedis further configured to: receive a machine learning-based nodebehavioral model; and applying, by the server, behavioral model to theredirected traffic from the particular node, to determine the nodeprofile for the particular node.
 11. The apparatus as in claim 10,wherein the process when executed is further configured to: detect adeviation in a behavior of the node based on the redirected traffic andon the determined node profile for the node.
 12. The apparatus as inclaim 10, wherein the apparatus determines the node profile for theparticular node based in part on the analysis of the redirected trafficby: training a machine learning-based node behavioral model usingtraffic from one or more other nodes; and analyzing the redirectedtraffic from the particular node using the trained node behavioralmodel.
 13. The apparatus as in claim 12, wherein the node behavioralmodel is trained using the traffic from the one or more other nodesafter boot of the one or more other nodes.
 14. The apparatus as in claim10, wherein the apparatus analyzes the redirected traffic from theparticular node using the trained node behavioral model by: deploying anode behavioral model to a networking device in the LAN, wherein thenetworking device uses the node behavioral model to analyze trafficassociated with the particular node that is not redirected to theapparatus.
 15. A tangible, non-transitory, computer-readable mediumstoring program instructions that, when executed by a device in anetwork, cause a server to perform a process comprising: instructing, bythe server, one or more networking devices in a local area network (LAN)to form a virtual network overlay in the LAN that redirects trafficassociated with a particular node in the LAN to the server; receiving,at the server, the redirected traffic associated with the particularnode; determining, by the server, a node profile for the particular nodebased in part on an analysis of the redirected traffic; and configuring,by the server, the particular node based on the determined node profilefor the particular node.
 16. The computer-readable medium as in claim15, wherein the process further comprises: receiving, at the server, aset of node behavioral rules; and applying, by the server, the set ofnode behavioral rules to the redirected traffic from the particularnode, to determine the node profile for the particular node.
 17. Thecomputer-readable medium as in claim 15, wherein the process furthercomprises: receiving, at the server, a machine learning-based nodebehavioral model; and applying, by the server, behavioral model to theredirected traffic from the particular node, to determine the nodeprofile for the particular node.
 18. The computer-readable medium as inclaim 15, wherein analyzing the redirected traffic from the particularnode using the trained node behavioral model comprises: deploying, bythe server, a node behavioral model to a networking device in the LAN,wherein the networking device uses the node behavioral model to analyzetraffic associated with the particular node that is not redirected tothe server.
 19. The computer-readable medium as in claim 15, whereindetermining the node profile for the particular node based in part onthe analysis of the redirected traffic comprises: training, by theserver, a machine learning-based node behavioral model using trafficfrom one or more other nodes; and analyzing, by the server, theredirected traffic from the particular node using the trained nodebehavioral model.
 20. The computer-readable medium as in claim 19,wherein the node behavioral model is trained using the traffic from theone or more other nodes after boot of the one or more other nodes.